home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-3154 / 525.txt < prev    next >
Text File  |  1992-05-11  |  33KB  |  772 lines

  1. Info-Atari16 Digest         Sat,  5 Oct 91       Volume 91 : Issue 525
  2.  
  3. Today's Topics:
  4.                             ARJ? (3 msgs)
  5.                               For Sale :
  6.                                Help!?!
  7.                  Install an app for two diff filetype
  8.                                KR2ANSI
  9.                     lharc vs. zoo (my correction)
  10.      Need disk cat prog. to show disk files & sizes, ask comments
  11. People dumping machines (was.. Atari Mega 2 system.. for sale) (3 msgs)
  12.                       Railroad Tycoon Needs File
  13.   SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!!
  14.                       Spectre GCR/System 7/A/UX
  15.               Using gcc/g++ to cross compile for the ST
  16.           WANTED: Suggestions for ST color monitor purchase
  17.  
  18. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  19. cross-posting to/from Usenet is getting closer, but still getting thrashed
  20. out.  Please send notifications about broken digests or bogus messages
  21. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  22.  
  23. Please send requests for un/subscription and other administrivia to
  24. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  25. instead of the moderators are likely to be lost or ignored.
  26.  
  27. If you want to unsubscribe, and you're receiving the digest indirectly
  28. from someplace (usually a BITNET host) that redistributes it, please
  29. contact the redistributor, not us.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: 2 Oct 91 20:45:04 GMT
  33. From: mcsun!unido!mcshh!malihh!pfunk!blackbox@uunet.uu.net (Michael
  34.  Kistenmacher)
  35. Subject: ARJ?
  36. To: Info-Atari16@naucse.cse.nau.edu
  37.  
  38. In <1991Oct01.144917.1607@convex.com>, William Rosenkranz writes:
  39.  
  40. >sort of program. when i post code, i generally always post source. and i
  41. >place no restrictions on its use at all. i generally don't even include
  42. >a copyright. and the code i write ends up in some odd places (nroff became
  43.  
  44. I pay high respect to your attitude, above all if I look on the products,
  45. you have added to the PD-section on the ATARI. But you have to realize that
  46. some people have to pay their rent with that money. Thomas is a student
  47. and his university demand a high contribution. I don't know anything
  48. about your profession but some people must earn money with their products.
  49. >
  50. >requesting the source, in this case, will save me the time of disassembling
  51. >it, correcting the disassembled source, reformatting it, and annotating
  52.  
  53. If all people would thing think like that and every part of software would
  54. be free of charge, we would not have so much professional software for
  55. our computer. This might sound a bit fancy, but if I make a list of
  56. professional products for the ST, the amount of them from germany would
  57. perhaps be higher.(please don't get that wrong)
  58.  
  59. >i would not disassemble a spreadsheet, database, or any other sort of program.
  60. >but for me, archivers are different.
  61. >
  62. But where do you make the difference ? OK, some hours against some weeks.
  63.  
  64. Bye......Michael
  65.  
  66. --
  67. /------------------------------------\
  68. | Michael Kistenmacher /  blackbox   |
  69. | 2000 Hamburg 61  / Schippelsweg 64 |
  70. | West Germany / ++ 49 40 552 37 66  |
  71. \------------------------------------/
  72.  
  73. ------------------------------
  74.  
  75. Date: 3 Oct 91 07:52:17 GMT
  76. From: mcsun!uknet!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth)
  77. Subject: ARJ?
  78. To: Info-Atari16@naucse.cse.nau.edu
  79.  
  80. In article <1991Oct1.212652.15376@watdragon.waterloo.edu>
  81. cjherborth@rose.waterloo.edu (Chris Herborth) writes:
  82. >a) What's the problem with Malloc() inside an ACC?  Beyond the possibility
  83. >   of fragmenting your memeory, I can't imagine anything going wrong...
  84.  
  85. Like I said, when you malloc memory from an acc, the memory belongs to the
  86. current process not the accessory. So if you are in an application when you
  87. malloc some memory, you'll lose it when that application terminates. The
  88. desktop doesn't terminate so you should do your mallocing then.
  89. I'm not sure about rez changes though. Perhaps the desktop 'quits' then.
  90. I guess you'd have to catch that.
  91.  
  92. >The main point is, it's to be an EXTENSIBLE Screen Saver.  You could have
  93. >2M of modules sitting in your XScreen folder (well, if it caught on and
  94. >lots of people wrote modules) and you wouldn't want to load them all when
  95. >you booted.  You'd just want to load the one that was going to be
  96. >executed when the screen saver went off.  When you were done (ie, work your
  97. >ST back up), it'd get deallocated.
  98.  
  99. What I described was an EXTENSIBLE system. You might have to reserve memory
  100. for saver slots in advance though.
  101.  
  102. >There's another problem --> I haven't got the assembler smarts to write
  103. >any sort of code that'll relocate and execure a module the way you
  104. >suggest, with a special header/whatnot.  I can't even use XBRA without
  105. >the routines somebody else wrote and uploaded to a.a...
  106.  
  107. Well you are going to have to learn about assembler anyway to write
  108. the saver in the first place.
  109.  
  110. BTW I'm getting all this stuff in reverse so I'm replying without having
  111. seen Ken's message yet. No doubt I've made some more screw-ups! :-)
  112.  
  113. +----------------------------------------------------------------------------+
  114. ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
  115. !                                                                            !
  116. ! Neil Forsyth                      JANET:  neil@uk.ac.hw.cs                 !
  117. ! Dept. of Computer Science         ARPA:   neil@cs.hw.ac.uk                 !
  118. ! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
  119. ! Edinburgh, Scotland, UK           "That was never 5 minutes!"              !
  120. +----------------------------------------------------------------------------+
  121.  
  122. ------------------------------
  123.  
  124. Date: 2 Oct 91 23:01:35 GMT
  125. From:
  126.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
  127.  .ohio-state.edu!usenet.ins.cwru.edu!yfn.ysu.edu!ysub!psuvm!cunyvm!jokhc@arizona
  128.  .edu (Joshua Kronengold)
  129. Subject: ARJ?
  130. To: Info-Atari16@naucse.cse.nau.edu
  131.  
  132. You don't want to malloc in a desk acc inside a application, because once you
  133. are closed, anyone else can use that memory.
  134.                    A easy Idea, might be to make savers written in some type of
  135. interpred language,or script.  If you distribute an interpreter with it, litera
  136. ly anyone can make up their own saver...
  137.  
  138.    To be really simple, the 'language' could just be an animation format...
  139.  
  140. -------
  141. < Joshua Kronengold<JOKHC@CUNYVM.cuny.edu>                            >
  142. < "Oh Lord, what fools these mortals be!"-Robin Goodfellow            >
  143. < "Never underestimate man's potential for stupidity"                 >
  144. <    <I'm going to change this soon, >  -Woodrow Wilson Smith         >
  145.      <I promise...                   >
  146.  
  147. ------------------------------
  148.  
  149. Date: 3 Oct 91 00:49:34 GMT
  150. From:
  151.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ox.com!math.fu-berlin.de!fu
  152.  b!dobag.in-berlin.de!obh.in-berlin.de!tyrell@arizona.edu (Stefan Haack)
  153. Subject: For Sale :
  154. To: Info-Atari16@naucse.cse.nau.edu
  155.  
  156. For Sale :       ATARI 'TETRA-TOWER'
  157.         -Atari Mega ST 4 Board  4MB
  158.         -AT-Speed C 16 (16Mhz)          (MS-DOS Emulator)
  159.         -Hypercash      16Mhz
  160.         -Overscan
  161.         -all Tetra Tool's(Printer, I/O, SCSI, LAN)
  162.         -177 MB Seagate Harddisk (14ms 64KB Cache)
  163.         -44 MB Syquest SQ44
  164.         -3 1/2 Disk
  165.         -5 1/4 Disk
  166.         -NEC 3D Multisync
  167.         -ATARI SLM804
  168.         -Calamus DestopPub. Program and another Programs
  169.  
  170.                         VB 9500.- DM   (Deutsche Mark) without Shipping !
  171.  ------------------------------------------------------------------------
  172.  Voice Germany 030/3235284 Q Rigo Manikofski or Stefan Haack
  173.  or mail me !                     tyrell@obh.in-berlin.de
  174.  
  175. ------------------------------
  176.  
  177. Date: Sat, 05 Oct 91 16:19:13 MEZ
  178. From: Wolfgang Ley <BWWL%DCZTU1.BITNET@CUNYVM.CUNY.EDU>
  179. Subject: Help!?!
  180. To: Atari ST users forum <Info-Atari16@naucse.cse.nau.edu>
  181.  
  182. On Fri, 4 Oct 1991 21:17:00 MST <ASMVF@ASUACVAX> said:
  183. >Hello, folks!
  184. >
  185. >I am new to Bitnet and Internet, and need a little help, if you can spare
  186. >it.
  187. >
  188. >I am interested in doing anonymous ftp to get some atari st software.  I
  189. >tried a couple of the addresses on the list that was sent out in
  190. >yesterday's digest, but I couldn't get past the login.  Is there some kind
  191. >of universal guest account or something?
  192. >
  193. >Thanks in advance!
  194. >
  195. >*Mf*
  196.  
  197. Hi!
  198.  
  199. There is indeed a special account:
  200. 1) you should login as "anonymous" (most of the ftp-sites also understand
  201.    the userid "ftp", but "anonymous" is the best way...)
  202. 2) send your userid as password. Most server accept the name "guest", but
  203.    normally you should send your own userid. Some even want the complete
  204.    mailing address as password (like BWWL@ibm.rz.tu-clausthal.de)
  205. This should work...
  206.  
  207. I hope this helps. Bye, Wolfgang.
  208.  
  209. (bye the way: the most important ftp-site for atari is
  210.  atari.archive.umich.edu (141.211.164.8)   )
  211.  
  212. ---------------------------------------------------------------------------
  213.        Wolfgang Ley                e-mail:
  214.        Teichstrasse 9              from BITNET  : BWWL@DCZTU1.BITNET
  215. W-3392 Clausthal-Zellerfeld        from Internet: BWWL@ibm.rz.tu-clausthal.de
  216.        (West Germany)                         or  BWWL@sun.rz.tu-clausthal.de
  217.        Tel. 05323/82132 (voice)
  218. ---------------------------------------------------------------------------
  219.  
  220. ------------------------------
  221.  
  222. Date: 2 Oct 91 19:55:04 GMT
  223. From:
  224.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon
  225.  h!jhenders@arizona.edu (John Henders)
  226. Subject: Install an app for two diff filetype
  227. To: Info-Atari16@naucse.cse.nau.edu
  228.  
  229. In <5551365@presto.ruhr.de>, David Channing writes:
  230. >In article <6446.28e738d9@miavx1.acs.muohio.edu>
  231.  rlcollins@miavx1.acs.muohio.edu
  232. >(Ryan 'Gozar' Collins) writes:
  233. >>
  234. >> 1. Is there anyway to install an application for more than one filetype?
  235. >> filetype. Well, it won't let you do that under 1.4 :*(  So I tried to
  236. >> edit the desktop.inf file adding the required lines to install the
  237. >> application for two filetypes. Well, my ST just crashed on boot up
  238. >
  239. >You must have messed up your desktop.inf file editing it. Here are the
  240. >relevant lines from my desktop.inf which works with no problems:
  241. >
  242. >#F FF 04   C:\BIN\ARCLOAD.PRG@ *.ARC@
  243. >#F FF 04   C:\BIN\ARCLOAD.PRG@ *.LZH@
  244. >#F FF 04   C:\BIN\ARCLOAD.PRG@ *.ZOO@
  245. >
  246.  
  247.         This only works until the next time you save a desktop.inf
  248. file from the desktop. The desktop seems to ignore the extra
  249. lines when writing the file, at least when I tried it.
  250.         The best solution is Gemini, where you can do something
  251. like *.[ALZ][RZO][CHO] in the instal application dialog. I'd
  252. sure like to have Gemini run from a ROM cart.
  253.  
  254. --
  255.           John Henders                      jhenders@jonh.wimsey.bc.ca
  256.           Vancouver,B.C                     or ubc.cs!van-bc!jonh!jhenders
  257.  
  258. ------------------------------
  259.  
  260. Date: 3 Oct 91 05:55:56 GMT
  261. From: bu.edu!bucsf.bu.edu!harryk@uunet.uu.net (Harry Karayiannis)
  262. Subject: KR2ANSI
  263. To: Info-Atari16@naucse.cse.nau.edu
  264.  
  265.   I just put kr2ansi.zoo on atari.archive. kr2ansi is a small utility that
  266. generates ANSI prototypes from K&R-style C source files.
  267.  
  268.   Using output redirection one can generate header files (the program puts
  269. an "extern" in front of every prototype line) with prototypes of all the
  270. functions present in the file read...with the appropriate #include lines in
  271. the K&R source code old-fashioned programs can be compiled with an ANSI
  272. compiler (thus taking advantage of the parameter-checking during compilation).
  273.  
  274.   If there's enough interest I can also send it to c.b.a.s and c.s.a.s
  275.  
  276. have fun...
  277.  
  278.  
  279. ===============================================================================
  280. Author of ATZENTA2           Harry Karayiannis          ________E-Mail_________
  281.                      15 N.Beacon, #316   Boston Univ.  |INTERnet:
  282. **  || ATARI   **    Allston, MA 02134   Computer Sc.  |    harryk@bucsf.bu.edu
  283. ** /||\ MegaST **    U.S.A.                            |BITnet:
  284. =======================================================|  cscrzcc@buacca.bu.edu
  285.                                                         -----------------------
  286.  
  287. ------------------------------
  288.  
  289. Date: 3 Oct 91 13:25:41 GMT
  290. From:
  291.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!news@ar
  292.  izona.edu (WALLMANN, GEORG)
  293. Subject: lharc vs. zoo (my correction)
  294. To: Info-Atari16@naucse.cse.nau.edu
  295.  
  296. As two people have pointed out I lost 'cause I oversaw the 'h' option
  297. on Zoo 2.1. I ran the tests again and sure enough the results of ZOO
  298. came very close to Lharc. Which makes conclusion wise ZOO as good
  299. as Lharc really.
  300.  
  301. As to the fragmentation issue, I don't still quite see the problem (but
  302. who cares ? (har)) since after erasing the produced files, the fragmen-
  303. tation ought to be the same as before (the allocated blocks being freed).
  304. BTW. Since all archivers ran on the same partition from the same /bin
  305. directory I don't see this comparable to running one from a floppy and
  306. one from a ramdisk, not even in a more transcendental sense.
  307.  
  308. Oh well
  309.         Nat!
  310.  
  311. ------------------------------
  312.  
  313. Date: 3 Oct 91 04:19:17 GMT
  314. From: noao!asuvax!cs.utexas.edu!samsung!mips!apple!netcomsv!bryanw@arizona.edu
  315.  (Bryan Woodworth)
  316. Subject: Need disk cat prog. to show disk files & sizes, ask comments
  317. To: Info-Atari16@naucse.cse.nau.edu
  318.  
  319. I am looking for a program that does the following:
  320.  
  321. o catalogs filenames and filesizes according to disk #s
  322. o asks for comments
  323. o stores output in !! ASCII !! format.
  324.  
  325. Any ideas?
  326.  
  327. --
  328. Bryan Woodworth   Mail: bryanw@netcom.COM
  329. Netcom - Online Communication Services San Jose, CA
  330.  
  331. ------------------------------
  332.  
  333. Date: 3 Oct 91 23:35:36 GMT
  334. From:
  335.  noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc
  336.  e@arizona.edu (Joachim Vance)
  337. Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
  338. To: Info-Atari16@naucse.cse.nau.edu
  339.  
  340. In article <1991Sep27.143553.27920@magnus.acs.ohio-state.edu>
  341. dhbutler@magnus.acs.ohio-state.edu (David Butler) writes:
  342.  
  343.  > One thing I have noticed about the computer world is that there are
  344.  > a lot of real bone-heads in it, like as in thick skulls. Atari and
  345.  > Amiga users are the WORST of the lot. Get off your high-horses guys,
  346.  > you are arguing over a hunk of frigging silicone and some wires!
  347.  > That's right, go home, look at your ST, and think about what it really
  348.  > is, a lump of PLASTIC and METAL, and that is all, it has no
  349.  > importance. GET A LIFE!
  350.  
  351.      Didn't you know?  Computers are a bona fide social religion.
  352. Just like cars, beer and music.  Computers, for some people, have as much
  353. to do with a person's self esteem and self image as clothing and
  354. hairstyle (or more so).
  355.     What more to life is there anyway ;)
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378. --
  379. Joachim Vance
  380. =====================================================================
  381.      I am antisesquipedalian--Opposed to the use of long words.
  382. =====================================================================
  383.  
  384. ------------------------------
  385.  
  386. Date: 3 Oct 91 23:45:15 GMT
  387. From:
  388.  noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc
  389.  e@arizona.edu (Joachim Vance)
  390. Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
  391. To: Info-Atari16@naucse.cse.nau.edu
  392.  
  393. > though, like I said, if the blitter can speed up bit-block transfers...
  394.  
  395.   My understanding is that the TT has no blitter.  The '030 was too fast
  396. to justify one. Am I mistaken?
  397.  
  398. Joachim
  399. --
  400. Joachim Vance
  401. =====================================================================
  402.      I am antisesquipedalian--Opposed to the use of long words.
  403. =====================================================================
  404.  
  405. ------------------------------
  406.  
  407. Date: 4 Oct 91 00:41:46 GMT
  408. From: munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick@uunet.uu.net
  409.  (Warwick Allison)
  410. Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
  411. To: Info-Atari16@naucse.cse.nau.edu
  412.  
  413. In <28EBAB8B.5952@ics.uci.edu> jvance@bonnie.ics.uci.edu (Joachim Vance) writes:
  414.  
  415. >> though, like I said, if the blitter can speed up bit-block transfers...
  416.  
  417. >  My understanding is that the TT has no blitter.  The '030 was too fast
  418. >to justify one. Am I mistaken?
  419.  
  420. That was my guess, from seeing the "Blitter" option greyed out (ie. disabled)
  421. on my friend's TT.  It seems to me that if TurboST and QuickST can do better
  422. than the blitter (though I'm still not convinced), then certainly even the
  423. coders at Atari can do better with a 32MHz machine.
  424.  
  425. Warwick.
  426. --
  427.   _-_|\       warwick@cs.uq.oz.au
  428.  /     *  <-- Computer Science Department,
  429.  \_.-._/      University of Queensland,
  430.       v       Brisbane, AUSTRALIA.
  431.  
  432. ------------------------------
  433.  
  434. Date: 2 Oct 91 20:30:08 GMT
  435. From:
  436.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon
  437.  h!jhenders@arizona.edu (John Henders)
  438. Subject: Railroad Tycoon Needs File
  439. To: Info-Atari16@naucse.cse.nau.edu
  440.  
  441. In <4990@chalmers.se>, Per Anders Olausson writes:
  442. >
  443. >  There is a lot of bugs present when you have lost a game etc but I still
  444. >  haven't found myself trapped when *in* the game.
  445. >
  446. >  In other words I don't think the external bugs have any counterparts when
  447. >  running the game itself.
  448. >
  449. >  It sure is the first buggy Microphrose game I've owned anyway and I don't
  450. >  like it at all, they used to produce stuff that were better tested than this.
  451. >
  452.  
  453.         F19, on North American TOS's had several annoying bugs, the worst
  454. of which was that you'd suddenly find yourself flying inverted. Not
  455. fun if you were 100 feet off the ground at 400 mph. ;-) After promising
  456. to fix this for several months, Microprose announced that they didn't
  457. consider North American sales significant enough to warrant the effort.
  458.         While the bugs may not be a major problem on European TOS's, the
  459. early reports over here are that the game will barely run on most machines,
  460. some only work if you don't touch the mouse, and 4 meg machines are
  461. completely out of luck.
  462.         It's too bad, as this game's release for the ST was one reason I
  463. put off purchasing a clone, as unlike Richard Covert, I consider the
  464. 386 boxes the current top games machine.
  465.  
  466.  
  467.  
  468. --
  469.           John Henders                      jhenders@jonh.wimsey.bc.ca
  470.           Vancouver,B.C                     or ubc.cs!van-bc!jonh!jhenders
  471.  
  472. ------------------------------
  473.  
  474. Date: Sat, 05 Oct 91 03:02:45 SST
  475. From: "S. Ssuthipuntha" <AKISUJAR%NUSVM.BITNET@CUNYVM.CUNY.EDU>
  476. Subject: SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!!
  477. To: INFO-ATARI16@naucse.cse.nau.edu
  478.  
  479. Subject: Some (hopefully not redundant) Information
  480.  
  481. Greeting from Singapore,
  482.  
  483. * I am wondering why the mainframe here alway turns the Subject: line
  484.   into uppercase!
  485.  
  486. Contemplating to buy NeXT, I posted a message regarding the Mac
  487. Emulator to NEXT-L@BROWNVM.BITNET without much expectation as I
  488. so get use to getting zero response or help when I posted my queries
  489. here.  To my surprise I received 4 replies within 6 hours after
  490. sending out my messages.  Either the NeXT users are more enthusiastic
  491. about their computer than us, Atarians, or they are to free as they
  492. don't have to read the flaming which often occur in our discussion
  493. group. Perhaps the Ferrari owners (is it really a Ferrari?) or those
  494. who have an opportunity to drive/use without having to own one
  495. themselves could not be bother to spend their time debating or
  496. arguing whether the Toyota is better than Nissan.
  497.  
  498. Below is some parts of the reply which I felt might be of interest to
  499. all who are using Spectre or waiting for Spectre 256 (a Color Mac
  500. Emulator).
  501.  
  502. Suthipuntha, School of Architecture, National University of Singapore
  503.              AKISUJAR@NUSVM.BITNET
  504. -------------------------------------------------------------------
  505.  
  506. Hello,
  507.  
  508. I received the following from Abascus, the people working on a
  509. commercial Mac-emulator for the NeXT. The MIT effort has been halted
  510. because they don't see any point in duplicating Abascus' effort.
  511. Apparently, the MIT folks thought that Abascus is so far ahead of
  512. them that it wouldn't be worth their while to try to catch up
  513. anyways. Instead, they might try to work together.
  514.  
  515.  
  516. ===================================================================
  517.  
  518. Greetings,
  519.  
  520. Your presence at this conference implies an interest in open computing.
  521. At Abacus Research and Development, ARDI, we too are interested in open
  522. computing.  Specifically we are interest in helping you run programs that
  523. are currently available only on Apple's(r) Macintosh (r) computer.  We
  524. are a small start up with big goals.
  525.  
  526. Information that you have asked for that isn't contained in one of those
  527. three missives is answered below.
  528.  
  529. Q:  Performance?
  530. A:  Compute intensive applications blaze (the native 040 does all the work,
  531.     we just stand back and let it rip).  Graphics are slowed down by two
  532.     things.  ROMlib is written entirely in C so our graphics start out a
  533.     bit slower than Apple's, on top of that we go through NeXTstep and
  534.     that slows us down a bit more.  I believe most people who have seen
  535.     a demo are happy with the graphics.  Some of our graphics tests run
  536.     faster on a 040 NeXTstation than on a Mac IIci, some run slower.
  537.  
  538. Q:  What special hardware is needed.
  539. A:  None.  With the beta software you'll be able to stick 1.4M Mac formatted
  540.     floppies into your drive and have the contents transferred to your hard
  541.     disk for use under Executor.
  542.  
  543. Q:  Has Apple seen your work?
  544. A:  At least one person from Apple stopped by at UNIX Open Solutions '91
  545.     (thanks to everyone who stopped by).  I have also sent two demo copies
  546.     to people within Apple and am about to send a third to Apple Europe.
  547.  
  548. Q:  Lawsuit?
  549. A:  Who knows?  No word of one yet.  We're prepared for one.
  550.  
  551. Q:  Is the emulator at the source level or binary level?
  552. A:  What we will be releasing, Executor, is a binary compatible "solution."
  553.     We started this game with a source compatible solution, ROMlib.  ROMlib
  554.     was briefly offered for sale on the Sun-3 line for $400.00 for a one
  555.     CPU copy.  We sold a few but lost our shirts by spending much too much
  556.     time explaining its use.  Source compatibility systems are complex and it
  557.     turns out there aren't a whole lot of people who are familiar with Mac
  558.     programming and UNIX programming.  We will re-offer ROMlib for ISVs, but
  559.     the cost will be much greater and we can't do that until we've hired some
  560.     support people which in turn is predicated on getting some funding or
  561.     selling some copies of Executor.
  562.  
  563. Q:  Can I pass information about Executor and ROMlib to other groups?
  564. A:  Please do.  We've tried to keep a good balance between hype and reality;
  565.     I hope you do as well.
  566.  
  567. Today we do not have any shrink-wrapped products available for you to purchase.
  568. We are just about to send beta copies of what will be our first product.
  569. The "not quite beta" software can be shown running on a NeXTstation in our
  570. booth.  Because this is a conference dedicated to open solutions, we are also
  571. running a in-house version that uses X-windows.  The software that we are
  572. demonstrating is known as Executor and it allows you to take shrink-wrapped
  573. products originally written on a Macintosh and run them on non-Apple machines.
  574. The product line we will support is the NeXT product line.
  575.  
  576. Emulating the Macintosh is no simple matter.  When people clone IBM-PCs they
  577. have the cooperation of Microsoft.  Microsoft wrote the operating system that
  578. runs on PCs and Microsoft is willing to sell copies to clone makers.  Because
  579. Apple wrote the operating system that runs on Macintoshes, in order to be able
  580. to do what we do we had to rewrite the Macintosh operating system from scratch.
  581. Because this is such an enormous task, our first product will have some
  582. limitations.  The first version will not support:  Color, Sound, Printing,
  583. Desk Accessories, System 7, or AppleTalk(r).  As we grow we will get rid of
  584. these limitations.  We will also support other product lines.  If you are
  585. interested in our technology but you already buy UNIX machines from someone
  586. other than NeXT, you may want to tell the company you deal with that you'd
  587. like to see our software running on their platforms.  We could use the
  588. exposure.
  589.  
  590. <Stuff deleted >
  591.  
  592. For the technically curious, here's a brief description of how Executor is
  593. put together.  Executor is actually a very small program (approximately 3000
  594. lines of C and assembly "glue") that uses a large library known as ROMlib.
  595. As the name implies, ROMlib is a library of routines that replaces those
  596. provided by the Macintosh ROMs.  Although Executor has some assembly
  597. language portions, ROMlib is written entirely in C and at various times ROMlib
  598. has been brought up on a wide variety of machines, including:  DECstations,
  599. VAXstations, SPARCstations, the IBM-PC running Xenix, Data General's Aviion,
  600. the IBM-RT as well as the machines we use in house, "Sun 3"s and NeXTstations.
  601.  
  602. We originally hoped independent software vendors would use ROMlib to port their
  603. applications to the wide range of platforms that will support ROMlib, but there
  604. were concerns that ROMlib wouldn't be robust enough to handle complex
  605. applications.  Executor was created both as a viable software product and as
  606. proof that ROMlib will work with complex programs.
  607.  
  608. We hope you like what you see and that you'll pass on your knowledge of our
  609. company and projects to your colleagues and to the manufacturer that supplies
  610. you with open solutions.  We welcome suggestions and are trying hard to grow as
  611. a company so that we can act on them.  Most suggestions so far have been
  612. "Support Color," Support Printing."  We will as soon as we can.  When we
  613. release our first product it will certainly be less powerful than what
  614. everyone wants (a product that runs on all platforms, executes all programs
  615. written on a Macintosh and has no limitations with respect to Color, Printing,
  616. etc.).  We humbly ask that you not buy our product until it does what you want.
  617. We don't want to disappoint anyone and sincerely believe that some people will
  618. benefit from our limited versions and it will be less of a hassle for each of
  619. us if you wait until we release what you really want before you become a
  620. customer.
  621.  
  622. ExecutorDemo is distributed on a floppy disk as a NeXT package.
  623. You must be super-user to do the installation because ExecutorDemo
  624. must be installed as a set-uid root program so it can load in kernel
  625.  
  626. <More Stuff deleted>
  627.  
  628. Once ExecutorDemo has been installed you should be able to run the
  629. sample programs provided by starting up ExecutorDemo and selecting
  630. the application you wish to run and then either completing a double
  631. click or selecting the "OK" button.  This document assumes you are
  632. already familiar with the Macintosh paradigm.
  633.  
  634.  
  635. <More stuff deleted>
  636.  
  637. The first release will run Microsoft Word 4.00D.  Other programs
  638. may work; but you are on your own.  The Microsoft Word "only"
  639. version will cost $80.00.  When it is fully debugged, a version
  640. that supports all major applications, Color, and Sound will cost
  641. $700.00.  The $80.00 version should be out in December 1991.  It
  642. is too early to predict when the full featured version will be
  643. available. Qualification for other applications shall be forthcoming
  644. as an interim solution.
  645.  
  646. <further more stuff deleted>
  647.  
  648.   people wouldn't believe our code would hold up with the heavy use of a
  649.   major application.  It does.  2) The legal implications.  We'd get a better
  650.   reception if we were selling flammable children's nightwear.
  651.  
  652.   I hope enough people were interested to justify this as a post rather than
  653.   e-mail.  I hope some comp.sys.next readers will see us at UNIX Open even
  654.   though NeXT won't be there.  Perhaps if enough show up we can go hit "Fondue
  655.   Fred" in Berkeley.
  656.  
  657. Thank you.
  658.  
  659.                 Sincerely,
  660.  
  661.                 Clifford T. Matthews
  662.                 President and founder
  663.                 Abacus Research and Development, Inc.
  664.  
  665.  
  666. It sounds like they still have much work to do on it, but seems to be well
  667. underway.  I hope this helps.
  668.  
  669. Suthipuntha,
  670.  
  671. ------------------------------
  672.  
  673. Date: 3 Oct 91 14:00:20 GMT
  674. From:
  675.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
  676.  .ohio-state.edu!dhbutler@arizona.edu (David Butler)
  677. Subject: Spectre GCR/System 7/A/UX
  678. To: Info-Atari16@naucse.cse.nau.edu
  679.  
  680. In article <"1028*.S=data3d.O=aahs.PRMD=uninett.ADMD=..C=no."@MHS> data3d@aahs.
  681. no (Karl Anders 0ygard) writes:
  682. >1 simple question: Does Spectre run System 7 and A/UX?
  683. >
  684. >Karl Anders Oygard - Karl A Oygard <data3d@aahs.no>
  685.  
  686. System 7 does not work as yet (and who wants it, have you used it? Man, talk
  687. about slow. Also uses over a MEG or ram just for the basic OS, they probably
  688. have Crays running on smaller operating systems. I have a theory the whole
  689. thing was written in basic, and is actually just a huge pracitical joke
  690. anyway). I don't know about A/UX. Dave Small will probably have system 7
  691. working soon for those who want it. As for A/UX, since Dave is a UNIX wiz, if
  692. it does not work at this time, I'm sure he is working on it, or can at least
  693. let you know one way or the other.
  694. - David Butler -
  695.  
  696. ------------------------------
  697.  
  698. Date: 3 Oct 91 04:38:44 GMT
  699. From:
  700.  news-server.csri.toronto.edu!generic.physics.utoronto.ca!julian!julian.uwo.ca!e
  701.  rsmith@uunet.uu.net (Eric Smith)
  702. Subject: Using gcc/g++ to cross compile for the ST
  703. To: Info-Atari16@naucse.cse.nau.edu
  704.  
  705. In article <1991Oct2.215945.25204@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov
  706.  (Howard Chu) writes:
  707. >I'm a little hazy on the MiNT support in the current version of gcc.
  708. >It causes the mint libraries to be loaded before the regular libraries,
  709. >but the mint library docs say "use this instead of the regular gnu
  710. >libraries." Some agreement/clarification would be nice.
  711.  
  712. The mint library docs were written before gcc 1.40 was available and
  713. before the gcc include files were adapted for MiNT (you can check the
  714. latter by grep'ing for __MINT__ in the include directory), so the
  715. confusion is understandable. Some clarification, then:
  716.  
  717. (1) You can keep the original gcc include files and libraries, and
  718. name the MiNT libraries as mint.olb and mint16.olb, and then use the
  719. "-mint" switch to gcc to use the MiNT libraries (e.g. gcc -mint
  720. foo.c). If you do this, the MiNT library will be searched first, and
  721. then the "normal" gcc library; it is highly unlikely that anything
  722. will actually be linked from the normal library, since the MiNT one is
  723. complete, so that second search does nothing. (Also: use the gcc
  724. library crt0.o).
  725.  
  726. You can use this set up if you want to use different libraries for
  727. different programs.
  728.  
  729. (2) Alternatively, you can throw out (or put on a backup disk) the old
  730. gcc libraries and use the MiNT ones (in this case, call them gnu.olb
  731. and gnu16.olb) and the MiNT crt0.o. In this case, you'll probably want
  732. to use the MiNT include files instead of the gcc ones, since they're
  733. smaller.
  734.  
  735. This is the setup I use, and it's the only one I can absolutely
  736. guarantee; on the other hand, I strongly suspect that (1) works as it
  737. should, since I trust bammi to get it right. Personally, I can see no
  738. reason *not* to use the MiNT library alone, so I see no reason to keep
  739. the "normal" one. However, mileage may vary.
  740.  
  741. (Do I see a reason not to use the normal library? Yes: UNIXMODE is a
  742. horrible abomination that causes code bloat and aggravation if you're
  743. trying to use a non-TOS file system (like minix) under MiNT. It was
  744. probably one of my worst ideas (or, if the idea wasn't bad, the
  745. implementation certainly was). MiNT is my penance for UNIXMODE :-) ).
  746. --
  747. Eric R. Smith   ersmith@julian.uwo.ca   eric.smith@uwo.ca
  748.  
  749. create a sensible (non-TOS) file system. It was my worst mistake, and
  750. believe me, I've done penance for it
  751.  
  752. ------------------------------
  753.  
  754. Date: 3 Oct 91 04:58:32 GMT
  755. From: pro-smof.cts.com!bgodot@ucbvax.berkeley.edu (Buck Godot)
  756. Subject: WANTED: Suggestions for ST color monitor purchase
  757. To: Info-Atari16@naucse.cse.nau.edu
  758.  
  759. I'm tired of using Video Key with a composite monitor.  It was an
  760. inexpensive option at the time, but I would like to get the real thing
  761. now.
  762.  
  763. Does anyone have any suggestions for a color monitor purchase?  Any
  764. warnings?
  765.  
  766. BTW, this is for a 1040 STf.....
  767.  
  768. ------------------------------
  769.  
  770. End of Info-Atari16 Digest
  771. ******************************
  772.